Pascal Public Domain Library Specifications This is simply my current thoughts and something to start arguing from. Howard Richoux 1. Licensing - Free to ALL, commercial and personal use. The only restriction is to require code source credit as appropriate. Copyright retained by who? 2. Target users: Borland Pascal version 7, real mode. Should wind up TP6 compatible with little effort. Will need help to assure protected mode compatibility. How about BPW? 3. Suggested structure: Until a better model is presented, I suggest the following: level 1 - one or more large TPUs containing general purpose, minimum global routines. Rely on linker to trim out un-referenced code and data. Use SYSTEM unit only, CRT adds a big chunk. "Hello world" program should be virtually unaffected by a uses of a level 1 unit. Use minimum of calls of other level 1 routines. level 2 - routines and objects referencing level 1 support. Try for minimum cross referencing of level 2 structures and code. level 3 - a single call might bring in 10s of K of code and or data from lower levels. Separate TPUs by functional area CRT, SOUND, SPEECH, ... level 4 - references commercial or otherwise restricted code. Requirements need to be spelled out. 4. Criteria for inclusion: - Nearly anything which is used more than once belongs in a library. - Resource use should be commensurate with benefits. Large functions need to be broken down so that the compiler can trim out unused code and data. 5. Coding standards. A lot of this is personal taste and habits, but some standardization is necessary to make it easy to code from memory rather than have to constantly refer to documentation. I keep finding inconsistancies in my own naming schemes, but I have found it best to fix them when detected rather than be faced with a much larger job down the road. External standards - I expect we should prefix every procedure and function name with something like Pb (for Public) to make it obvious where to look. I like having the last portion of the name indicate Function return type (like PbBooleanStr returning results as a string). Internal standards - Much tougher. I have a personal bias against code that looks like a snake: xxxxxx xxxx xxx xxxx xxxx xxx and I like: If xxxxx then begin yyyy end; I suspect that others will disagree violently. This is a discussion point. 6. Utility programs One of the keys to standards is the tools provided to support them. It would not be unreasonable to provide a program lister that could convert back and forth between styles. I have most of a "ChangeAll" program so I can change names easily. The USES utility helps resolve unit problems. TMAP has been very useful to me in turning TP map files into something that makes sense. the trouble is that about 5% of the information is either missing from the map file, or I just am interpreting it wrong. UNITSCAN builds a .dbf file of function and procedure names and a specific type of comment, from the interface section of a unit source file. It has limitations, but can be useful. By incorporating {section xxxx } type comments in the source files, I can use TPRINT to extract specific sections (such as interface info) into documents directly from the source code. SORTSECT can re-arrange the segments into alphabetical order. All of these utilities are 95% or so of what they really ought to be. They work, but have some minor unreasonable limitations. Documentation is minimal - I wrote them so I should know how they work (ha ha). With a little work, they could form the basis of a workable development environment. One of my other little utilities is TP, my substitute for the IDE. This is not ready for prime time, but it lets me work the way I want to. Someone else can re-program it totally differently if they choose.